The present invention relates to methods for extending the flow of information when transmitting a message, in particular a multimedia message, via a mobile radio network, in particular a UMTS network, and to corresponding apparatuses and software programs.
For the mobile radio system of the next generation UMTS (UMTS—Universal Mobile Telecommunications System), a variant of a mobile message service is currently being standardized which has a multimedia capability and is called MMS (MMS—Multimedia Messaging Service), see 3GPP TS 22.140 version 4.1.0, Release 4; Third Generation Partnership Project; Technical Specification Group Services and System Aspects; Service Aspects; Stage 1; Multimedia Messaging Service (MMS), and also 3GPP TS 23.140 version 4.3.0, Release 4; Third Generation Partnership Project; Technical Specification Group Terminals; Multimedia Messaging Service (MMS); Functional Description; Stage 2.
Messages having multimedia contents are merely called MMs for short (MM—Multimedia Message) in order to provide better distinction from the text messages of the SMS. In contrast to the SMS, there is no longer any limitation to pure text contents. The MMS will allow texts to be formatted on the basis of individual taste and will allow audio and video contents to be embedded into a message.
FIG. 1 shows the MMS network architecture on the basis of today's prior art from the point of view of 3GPP (Third Generation Partnership Project). An MMS User Agent (abbreviation: UA) is understood to be an application, for example on a mobile radio telephone or on a unit connected to a mobile radio telephone (e.g., a laptop, or the like), which implements MMS. The application from which a message is sent is referred to below as the transmitting application, in the specific MMS Agent A (abbreviated to UAA in this case), and the application that receives is referred to as the receiving application, in the specific MMS User Agent B (abbreviated to UAB in this case). In accordance with FIG. 1, a transmitting application UAA 1 uses an air interface, denoted by MM1, to send an MM via a radio network 7 to the network unit 5, denoted by MMS Relay/Server A (abbreviated to RSA in this case; MMS Relay/Server is abbreviated to RS below), which provides the MMS functionality for the UAs in the domain of an MMS service provider 3 (MMS Service Provider A), the “MMSE” (MMSE—Multimedia Messaging Service Environment). An interface MM4 is then used to forward the message to a network unit 6, denoted by MMS Relay/Server B (RSB for short), in the domain of a recipient MMS service provider 4 (MMS Service Provider B), which in turn uses an interface MM1 to transmit the message to the receiving application UAB 2 via a radio network 8.
FIG. 1 shows the general case in which the originator network unit RSA 1 and the recipient network unit RSB 2 are not identical. The special case of just one MMSE involved is also known in the prior art, however, as is the fact that the interface MM1 does not necessarily need to be in the form of an air interface.
A feature of the MMS for the aforementioned special case of the originator and recipient RSs being identical (which feature is described in the above specification 3GPP TS 23.140 version 4.3.0, Release 4) is “Reply-Charging”, on the basis of which an originator sending an MM can express his/her readiness to accept the costs for a reply message, in particular a multimedia reply (Reply-MM), from the recipient. In this context, the originator can additionally specify a time limit as well. If an MM with appropriate reply charging identification is available to the recipient for downloading on the network element RS, the recipient is first notified and can then download the MM to his/her terminal. In this context, the recipient is informed, both in the notification and when downloading the MM, of the fact that he/she can send a reply message relating to this “Original-MM” free of charge. If he/she wishes to make use of this, he/she need merely identify an MM compiled on his/her terminal as a Reply-MM relating to the previously received Original-MM and send it off. The reply charging functionality has to date been defined only within an MMSE. A detailed description can be found in annex E of 3GPP TS 23.140 version 4.3.0, Release 4.
All the information required for transporting an MM is entered, like the complementary information for the reply charging functionality, as information elements into the abstract messages defined in 3GPP TS 23.140 version 4.3.0, Release 4. If a unit involved in the data interchange (application UA or network element RS) does not detect an information element, this information element is passed through unaltered. This behavior may be problematical for the reply charging functionality, since the above-described reply charging functionality based on the prior art works only if all the units involved in the data interchange (that is to say, both UAs and the RS) support the reply charging functionality. If, by way of example, only the transmitting application UAA and the receiving application UAB support the reply charging functionality, and the network element RS involved does not (perhaps because it supports an obsolete MMS version), the network element RS is not able to detect a Reply-MM and may not be able to reject it; i.e., the originator of the Reply-MM (=recipient of the Original-MM) incorrectly still believes that the costs for the Reply-MM which he/she has sent are being accepted by the recipient (=originator of the Original-MM).
The standardization committees 3GPP and WAP Forum are aware of a solution neither to the compatibility problem described above (network element RS does not support reply charging functionality) nor to the broadening of the reply charging functionality to cover a number of MMSEs.
The problem described also arises in other cases of a similar nature in which an originator requests a particular functionality from a service provider, without the originator and/or the recipient knowing whether the correspondingly implicated network units in the domain of one or more service providers support the requested functionality. By way of example, discussions are being held regarding the future introduction of other new functions, such as “Recall of MMS”, in the MMS which, although supported by the transmitting and receiving units, may not be supported by network units that are involved.
Another problem in the prior art is that the originator of an original message containing a reply charging indicator cannot protect oneself against the recipient sending an excessively long and, hence, very expensive reply message back.
It is an object of the present invention, therefore, to make transmitting information more user friendly when sending/receiving a message which contains a request for a particular functionality from an involved network unit in the domain of a service provider.